clickhouse的容器化部署，已经有非常成熟的生态了。在一些互联网大厂也已经得到了大规模的应用。

clickhouse作为一款数据库，其容器化的主要难点在于它是有状态的服务，因此，我们需要配置PVC。

目前业界比较流行的部署方式有两种：

本文以 clickhouse-operator为例，来讲解clickhouse容器化的步骤以及注意事项。

我们可以直接下载clickhouse-operator的yaml文件用于部署。

文件路径如下：

https://raw.githubusercontent.com/Altinity/clickhouse-operator/master​raw.githubusercontent.com/Altinity/clickhouse-operator/master/deploy/operator/clickhouse-operator-install-bundle.yaml

直接使用kubectl 应用上述yaml文件:

运行成功后，可以看到以下信息：

看到如上信息，说明operator部署成功。

我们从官网repo里找到一个最简单的单节点部署案例：

应用部署：

查询状态：

尝试登录该节点：

登陆成功，说明部署没有问题。

但是这种部署方式有一个问题，就是外部无法访问。

我们看它的service信息：

可以看到，它默认使用了LoadBalancer的service，而且它的EXTERNAL-IP是pending状态，这是因为clickhouse-operator默认我们在云环境上使用，在私服部署的话，我们并没有提供一个负载均衡器，因此无法选择IP，导致无法访问。

这时有两种解决方案：

我们先看第一种方式，安装metallb。安装步骤大家可自行网上搜索，安装成功后如下所示：

我们再次部署， 可以看到他给我们分配了一个192.168.110.198的IP, 注意，这个IP是真实存在的，也就是说，一定要有可分配的IP，才能成功。

验证该IP是否可用：

但是现在我们是不能从外部直接访问到这个clickhouse节点的。原因我们后面再说。

先看另一种解决方式，通过nodePort的方式来暴露端口。chi这个资源里提供了修改service的模板，修改如下：

此时查看service，得到如下结果：

同样，我们验证一下：

上例中，10.111.132.229是集群提供的cluster-ip，可以用pod内部端口访问，而192.168.110.186~192.168.110.188是k8s集群的节点IP，我们可以使用任意节点来访问。

这个端口虽然对外暴露出来了，但是我们并不能直接使用TCP的方式登录上去。除了default用户，clickhouse-operator还为我们提供了一个clickhouse_operator的用户，默认密码是clickhouse_operator_password，但是目前这两个用户都无法从外面访问。

这两个用户肯定是有效的，我们可以从pod内部登录访问：

为什么会如此，我们打开用户的配置文件：

可以看到，clickhouse_operator用户仅仅对内部ip开放，而default用户仅仅对本地回环开放以及hostname满足内部正则表达式规则的主机名开放，所以外面是无法登录的。那这样我们仍然用不了。

解决方案仍然有两种：

我们先看第一种方法。

我们可以在configuration里增加users的信息，比如我们增加一个叫chenyc的用户：

查看配置文件：

但是我们发现仍然访问不了，因为仍然有下面这段权限限制：

似乎第一种方案已经走入死胡同了，接下来我们来尝试第二种方式。

我们先看看clickhouse-operator源码中是如何处理用户的访问权限的。

根据DefaultUserInsertHostRegex变量来判断是否要配置host_regexp, 而该变量默认是true：

ip的限制则取决于配置的additional ip列表。

因此，我们只需要将additional IP以及host_regexp的规则在clickhouse_operator的yaml中去掉即可。

chop就是clickhouse_operator用户，它的ip限制主要取决于OPERATOR_POD_IP环境变量。而该环境变量可以通过clickhouse_operator的yaml传入，它默认是取的pod的IP，我们将其设置成::/0， 即可所有人都能访问了。

同样也是修改yaml。

有了以上的基础，我们直接修改yaml：

原始yaml：

修改后yaml：

修改前yaml：

修改后yaml：

以上内容修改完成后，重新apply clickhouse-operator。实际上，chop的用户我们也可以通过yaml去修改。比如我们将用户改成eoi，密码改成123456：

再次部署clickhouse, 查看配置文件：

从配置文件来看一切满足预期，我们尝试登录一下：

default用户可正常登录：

chop用户：

chenyc用户（自定义普通用户）：

以上就是通过修改operator的yaml，实现外部登录的过程。当然，像default用户、chop用户等有特殊含义的用户，实际使用时是不建议暴露出来让外界使用的。建议创建一个普通用户能让外界访问即可。

clickhouse作为一个数据库，最关键的自然是数据持久化的问题。那就意味着我们必须要使用PVC来指定持久化路径。下面是一个指定了持久化目录的例子：

前面提到过，clickhouse-operator默认是在云环境运行的。上面这段yaml在云环境是可以直接运行的，但是在私有k8s环境运行会报错。可以看到，其运行状态是pending。

使用describe去查看具体信息，得到如下报错：

以上错误是因为没有可用的持久化卷。我们可以通过自建nfs的方式提供一个PV来供挂载。

我们先在一台服务器上创建nfs service。

创建provisioner、storageclass：

应用：

成功应该可以查到以下信息：

我们将上述的yaml的pvc挂载到这个sc上：

再次查看，部署成功：

从nfs原始目录可以看到已经有目录挂载在上面：

clickhouse集群是依赖zookeeper的。clickhouse-operator项目官方很贴心地提供了pv方式部署以及emptyDir方式部署zookeeper的方案，且都提供了单节点和三节点的部署yaml。

我们这里以单节点持久化的场景为例：